Previous | 
Home
Section: Software
DIET
Participants : Yves Caniou, Eddy Caron [correspondent] , Frédéric Desprez, Maurice Djibril Faye, Adrian Muresan, Jonathan Rouzaud-Cornabas.
Huge problems can now be processed over the Internet thanks to Grid and Cloud middleware systems. The use of on-the-shelf applications is needed by scientists of other disciplines. Moreover, the computational power and memory needs of such applications may of course not be met by every workstation. Thus, the RPC paradigm seems to be a good candidate to build Problem Solving Environments on the Grid or Cloud. The aim of the Diet project (http://graal.ens-lyon.fr/DIET ) is to develop a set of tools to build computational servers accessible through a GridRPC API.
Moreover, the aim of a middleware system such as Diet is to provide a transparent access to a pool of computational servers. Diet focuses on offering such a service at a very large scale. A client which has a problem to solve should be able to obtain a reference to the server that is best suited for it. Diet is designed to take into account the data location when scheduling jobs. Data are kept as long as possible on (or near to) the computational servers in order to minimize transfer times. This kind of optimization is mandatory when performing job scheduling on a wide-area network. Diet is built upon Server Daemons. The scheduler is scattered across a hierarchy of Local Agents and Master Agents. Applications targeted for the Diet platform are now able to exert a degree of control over the scheduling subsystem via plug-in schedulers [85] . As the applications that are to be deployed on the Grid vary greatly in terms of performance demands, the Diet plug-in scheduler facility permits the application designer to express application needs and features in order that they be taken into account when application tasks are scheduled. These features are invoked at runtime after a user has submitted a service request to the MA, which broadcasts the request to its agent hierarchy.
Diet has been validated on several applications. Example of them have been described in Sections 4.3 through 4.5 .
DIET Security
We have worked on extending DIET to include security mechanisms. The first work was to provide authentication of users and components within DIET without breaking DIET distributed architecture. Our security mechanism must also be simple to use by the end users but we need a strong authentication. Recently, we have opted for Kerberos as it provided a Single Sign One that eases the security from the user point of view. Moreover, Kerberos provides strong authentication and works with heterogeneous systems. Work in progress is to integrate Kerberos within DIET. First, it will be used to provide traceability of user's actions and authentication of all DIET inner components. Then, it will be integrated in an authorization mechanism and other higher level security mechanisms.
GridRPC Data Management API
The GridRPC paradigm is an OGF standard, but the API appeared to lack of precision in order to make a GridRPC code portable to any GridRPC compliant middleware. Additionally required data have to be present on the client side (this can involve a potential transfer from where the data is stored onto the client), and transfers must be performed during the GridRPC call, both degrading performance, and can even make a calculus unfeasible.
Thus the GridRPC community has interests in Data Management within the GridRPC paradigm – Because of previous works performed in the Diet middleware concerning Data Management, Eddy Caron is co-chair of the GridRPC working group.
In consequence, we worked on a Data Management API which has been presented to almost all OGF sessions since OGF'21. Since september 2011, the proposal is an OGF standard, published at http://www.ogf.org/documents/GFD.186.pdf under the title “Data Management API within the GridRPC. Y. Caniou and others, via GRIDRPC-WG”. Some work are still in progress, like 1) the implementation of a library and its integration into GridRPC middleware, in order to publish a proof of concept of both realization and collaboration between two different GridRPC middleware supervising different domain platforms, and 2) a specific OGF document describing some parts of implementation to achieve code portability.